A batch's `status.code` appeared on the API reference as a bare list of
values with no explanation, and nowhere else in the docs. Readers seeing
a status in an API response, in the CLI, or on a dashboard chip had no
way to find out what it meant.

Add a Batch Status section to the data-types page, rendering a table
generated from the OpenAPI spec so the codes and their descriptions come
from the engine rather than being hand-maintained, and cross-reference it
from the monitoring and batches pages. The table goes through the shared
reader added earlier, so it already handles the shapes a synced schema
can arrive in — a `$ref` to a hoisted component in particular, which the
engine's enum deduplication produces.

Extend the anchor build gate to scan the API spec alongside the
configuration schema. This is the first data type marked in the API
spec, and schema syncs land as direct pushes to main, so the deploy
build is the only gate they pass through.

The bundled schemas are what the sync bot will deliver once the engine
side merges. They carry the per-value documentation as `x-mergify-enum`,
a positional array aligned with `enum` holding a description, an optional
display title and a deprecation flag, and the data-type marker under its
namespaced spelling. `x-enum-descriptions` is gone: that name is an
established openapi-generator convention for a positional array of
strings, and publishing a map under it would mislead the SDK generators
customers run against our spec.

Part of MRGFY-8330

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Change-Id: Ic5cd08016af10408a80c0d9f72b86dd61abc0a84